Information processing system and method for operation thereof

ABSTRACT

The invention relates to an information processing system and method for operation thereof, comprising: a central communication unit (ZDS) for the control and forwarding of information from a data set, at least one master information processing system, which communicates with the ZDS by means of an interface and which provides information for the ZDS on demand, at least one client information processing system, which communicates with the ZDS by means of an interface and which obtains information from the ZDS on request. Said information controlled by the ZDS is described by an object model, which comprises an conceptional object model (KOM), which describes the total data set as provided by the master and client systems and the views which are dedicated to the connected systems and describe all specific services related to the KOM, determine the elements of the data sets controlled by the ZDS, which said systems recognize.

[0001] The invention relates to an information processing system and amethod for its operation according to the preamble of the independentclaims.

[0002] The invention relates to the field of modeling complex systems.The starting point is an information processing system to be used forexchanging data between several technical applications. An importantproblem in modeling complex system is the match between the dynamic andstatic model views. The dynamic model view is typically represented byprocess models, whereas the static model view is represented by datamodels.

[0003] In conventional methods, the process typically proceeds asfollows:

[0004] 1. Modeling the processes

[0005] 2. Identifying the data required for the processes

[0006] 3. Combining and relating all data.

[0007] This method has a disadvantage of being quite inflexible withrespect to, for example, changes in or additions to the process and datastructure.

[0008] GB 2 319 863 A describes a so-called groupware system, inparticular for Internet/intranet applications, with a plurality ofclient applications that provides corresponding views of information.The information is stored in a central object database together with theprocesses applicable to the objects. Also provided is a plurality ofmachines with mechanisms for storing and manipulating the objects storedin the database. The system can advantageously be employed in computernetworks, whereby programs are downloaded from the network to theindividual network computers where they are executed, such as Javaprograms.

[0009] It Is the object of the invention to propose an informationprocessing system and a method for its operation, which simplifies aspecification and development of the interfaces between the technicalapplications.

[0010] This object is solved by the features of the independent claims.

[0011] The information processing system according to the inventionincludes a central communication unit (ZDS) (1) for administrating andforwarding information from a data set, at least one master informationprocessing system, which communicates with the ZDS via an interface andprovides the ZDS with information upon request, at least one clientinformation processing system, which communicates with the ZDS via aninterface and receives information from the ZDS upon request, whereinthe information administered by the ZDS is described by an object modelthat includes a conceptual object model (KOM) describing the entire dataset made available by the master and client systems, as well as viewsassociated with the connected systems and describing the correspondingspecific services related to the KOM, wherein the views determine theelements of the data set administered by the ZDS that are recognized bythe corresponding systems.

[0012] The invention is based on an object-oriented approach formodeling the processes. The object-oriented approach has the followingfeatures:

[0013] 1. Identification of independent objects or abstract units whichmanifest themselves to the outside through data uniformity and a uniformbehavior (object identification)

[0014] 2. Definition of the data and behavior characteristics of theseobjects

[0015] 3. Definition of processes as interaction between objects.

[0016] The object-oriented approach has the advantages that

[0017] objects that relate to real objects can be identified relativelyeasily (does not apply to abstract objects)

[0018] objects are typically smaller, less complex units than processes

[0019] objects have typically a longer validity than processes

[0020] different processes have a higher integration through commonlyused objects.

[0021] In addition, the object-oriented approach has the advantage thatit can be uniformly applied across all phases of the softwaredevelopment process (technicalconception/analysis—DP—conception/design—implementation/realization—operation/maintenance)which is not the case for conventional processes.

[0022] Advantageous embodiments and modifications of the invention arerecited in the dependent claims.

[0023] Advantageously, each master system provides to the ZDS theelements of its data set that are defined in a corresponding masterview, wherein the elements of the data set for which the system has thedata rights, are included in the master view of a connected mastersystem.

[0024] Simultaneously, each client system has access via a data accessservice to the data defined in a corresponding client view, wherein theelements of the data set, for which the system can recall informationfrom the ZDS, are included in the client view of a connected system.

[0025] In an advantageous embodiment of the invention, the views for theconnected systems are formed from the KOM by the operations Projectionand Selection.

[0026] A selection is made through the operation Projection, whichelements are to be included in a view in the form of Classes,Attributes, Methods, Relationships of the KOM.

[0027] Individual objects of the classes are selected by a Selection. ASelection is only possible in a client view. Preferably, a filter ruleis defined as a selection criteria for a class, with the filter ruledetermining which objects are included in the client view.

[0028] According to the invention, the corresponding view of the ZDSdetermines the elements of the KOM recognized by the connected system,wherein a view is described by:

[0029] classes with their

[0030] attributes and

[0031] methods (including interface)

[0032] selection criteria

[0033] relationships

[0034] consistency rules.

[0035] For communication with each other, at least two communicationmechanisms in the form of a data access service and a message serviceare provided to the connected master and client systems by the ZDS,wherein all services provided by the ZDS are defined as Methods in theobject model. Selection criteria can be applied to the services whichimpose additional limitations to the criteria defined for the classes.

[0036] The data access services are defined for both the client andmaster systems. The client systems define the data access services thatare technically required and to be used for accessing the data definedin the client view. Data access services for the master systems can thenbe defined from the requirements of the client data access services.

[0037] The message services within the ZDS object model are defined bothin master and client views. Changes in the data set of a master systemare transmitted to the ZDS via the message service and that the ZDSprovides these changes to the affected client systems.

[0038] In general, a separate class category is generated for eachsystem connected to the ZDS. Each class category can itself contain twoclass categories for master and client views.

[0039] The special class category KOM is subdivided into severalsubcategories formed according to certain criteria.

[0040] The class categories include:

[0041] exactly those classes (with attributes and methods) and theirrelationships that are visible in the corresponding view (5; 6),

[0042] at least one class diagram illustrating the classes included inthe view (5; 6),

[0043] for each operation, the specification of the signature of thismethod by identifying object structures.

[0044] The invention will be described hereinafter with reference to anembodiment illustrated in the drawings. The drawings and theirdescription convey additional features, advantages and applications ofthe invention. It is shown in:

[0045]FIG. 1 a high-level diagram of an information processing systembased on a ZDS;

[0046]FIG. 2 a diagram depicting the hierarchy of the class categoriesin the ZDS object model;

[0047]FIG. 3 a definition of the interface of a view;

[0048]FIG. 4 a tree structure of FIG. 3;

[0049]FIG. 5 a structure of message data;

[0050]FIG. 6 a representation of an update message with old and newvalues.

[0051] As shown in FIG. 1, a central data server ZDS 1 is implemented asa central communication unit between technical applications represented,for example, by master systems 3 and/or client systems 2. Employing theZDS 1 enables communication between these applications using uniformmethods based on a simplified view of the data. Each application system2; 3 requires only one interface to the ZDS 1. It is no longer necessaryto develop a separate interface between each of two communicatingsystems. This significantly reduces the development and maintenanceexpense for the interfaces.

[0052] The ZDS 1 is not an application system in the typical sense. Itdoes not perform any technical functions, nor does it offer a directuser interface or contains any technical data. Technical functions, userinterfaces and technical data storage are performed in the individualapplications systems 2; 3. The ZDS 1 accesses the data sets of theapplications systems with a read operation and offers services that canbe used by the applications systems to access the data sets of allconnected applications systems recognized by the ZDS. Since many of thetechnical data are processed only in a specific application system,typically only a portion of the data set is made publicly available viathe ZDS 1, namely the portion which is also used by the otherapplications systems for their tasks. The sum of all data setsaccessible via the ZDS 1 is described in a common model, the conceptualobject model (KOM) 4 of the ZDS 1.

[0053] The services of the ZDS 1 and the access thereto are identicalfor all connected systems 2; 3. However, the corresponding specificservices are described for each system in a separate view on theconceptual object model 4 of the ZDS 1. This specific view has to berecognized by the system and the ZDS 1 and is defined separately foreach system. Each connected systems can have two roles with respect tothe ZDS 1: as a master system 3 and/or as a client system 2.

[0054] A master system 3 provides to the ZDS 1 the portion of its dataset that is defined in the respective master view 6. The master systems3 also inform the ZDS 1 about changes in their own data set. A clientsystem 2 takes advantage of the possibilities provided by the ZDS 1 foraccessing the data defined in a client view 5. Messages about changeddata in the data set included in the client view 5 can be downloaded bythe client system 2 from the ZDS 1.

[0055] When the master view 6 and client view 5 are decoupled, certainchanges in the master views 6 do not affect the client views 5. This isparticularly the case if the responsibility for a data set is handedfrom one master system 3 to another. Two communication mechanisms areprovided by the ZDS 1 to the connected master systems 3 and clientsystems 2:

[0056] Data Access and Messages.

[0057] The Data Access service of the ZDS 1 gives the client systems 2access to the data sets defined in the ZDS 1. The resulting access tothe master systems 3 that are responsible for the desired data istransparent to the client systems 2, i.e., the client systems 2 do notknow which master systems 3 the requested data belong to.

[0058] The message service transmits changes in the data sets of amaster system 3 to the ZDS 1. The ZDS 1 then provides these changes tothe affected client systems 2.

[0059] The following table shows the information included in the masterand client views for Data Access and Message service: TABLE 1 contentsof the views on the ZDS Data Access Service Message Service Client whichdata can the in which messages regarding view client system requestchanges in the data set is the client system interested Master for whichdata has the master with changes of the data view system the data rightssets are transmitted to the ZDS

[0060] Several of the terms used in the context of object orientationwill now be explained:

Association

[0061] An association is the most common form of a relationship betweenclasses. It describes semantic and structure of a set of objectrelations.

[0062] The cardinality of the association determines how many objects ofthe related classes are part of an association.

[0063] The semantic of the relationship is described by providing rolenames, i.e., the role in which objects of one class view the objects ofthe other class. If an association has its own attributes, then this isan attributized association.

Attribute

[0064] An attribute is a data element that is included in each object ofa class and can have a separate value in each object.

[0065] An attribute is described by its name and its type.

[0066] Identifying attributes are distinguished in that they uniquelydetermine an object, i.e., there is no other object with the sameidentifying attributes.

Aggregation

[0067] The aggregation is a particular form of the more generalassociation relationship. The participating classes describe atotal/partial hierarchy, i.e., an aggregation describes how a totalentity is composed of its parts.

Class

[0068] A class is a set of objects that have a common structure and acommon behavior. The structure of a class is described by the attributesand relationships to other classes, the behavior by the operations of aclass.

Class Category

[0069] Class categories are used to subdivide the logical model. A classcategory can contain classes and other class categories. Unlike a class,however, a class category does not include operations or states of themodel.

Link

[0070] A link is a concrete relationship between objects. It is aninstance of an association.

Object

[0071] An object is a concrete unit, it has its state, a behavior and anidentity. Each object is an instance of a class. The information of anobject is represented by attributes, whose structure is defined in theclass. The behavior is determined by the operations defined in the classand is identical for all objects of a class.

Inheritance

[0072] The inheritance is a relationship between classes, wherein oneclass (subclass) is part of the structure and the behavior of the otherclass (superclass). The subclass is a special type of the superclass.

[0073]FIG. 2 shows the configuration of the ZDS object model 10 and therules for forming the views 5, 6 of the connected systems 2; 3.

[0074] The ZDS object model 10 is composed of the conceptual objectmodel (KOM) 4 and is the views 5, 6 of the connected systems. For thisreason, the entire model is subdivided into several categories, whereina separate category 11, 14, 17 is provided for each system connected tothe ZDS 1.

[0075] There exists a category ZDS-KOM 11 that includes KOM 4. KOM 4 inturn is arranged in several subcategories 12, 13 formed according totechnical criteria. The connected systems, e.g., system A and system B,each form a corresponding category 14, 17, wherein the name of thecategory which includes the view of the connected system on the ZDS 1 isassigned, for example, the postfix “View” (e.g., system A-view).

[0076] Each connected system can appear to the ZDS 1 as a master system3 and/or a client system 2. For this reason, the subcategories masterview 15 and 18, respectively, and client view 16 are established in thecategories 14, 17 depending on the role of the system.

[0077] As a result, the hierarchy of class categories depicted in FIG. 2is obtained, for example, for the ZDS object model 10 with the connectedsystems “System A” 14 and “System B” 17.

[0078] The view 5, 6 on the ZDS 1 determines the elements of KOM 4,which the connected system recognizes. The view is described by theincluded

[0079] classes with their

[0080] attributes and

[0081] methods (including interface)

[0082] selection criteria

[0083] relationships

[0084] consistency rules

[0085] The master view 6 of a connected system contains the elements forwhich the system is the “Master”, i.e., for which the system has in thedata rights. A primary master system is hereby defined for each class.This master system is responsible for the identifying attributes of theclass, but in many other cases also for other attributes. However, ifadditional systems are responsible for other attributes, then thesesystems are referred to as secondary master system. In the master viewsof the secondary master systems, the identifying attributes of the classare included in addition to their “own” attributes.

[0086] The client view 5 of a connected system includes the elements forwhich the system should be able to obtain information from the ZDS.

[0087] The views 5, 6 for the connected systems cannot be formedarbitrarily from the KOM 4. Allowed operations are Projection andSelection. Other operations, aside from Selection and Projection, arenot possible! For example, there is no operation Join, through whichseveral classes of the KOM 4 could be mapped on one class of a ZDSclient view 5.

[0088] The elements (classes, attributes, methods, relationships) of theKOM 4 to be included in a view 5, 6 are selected via a Projection. Allother elements of the KOM 4 are disregarded by the Projection.

[0089] A Selection is only possible in a client view 5. Individualobjects of the class can be selected by a Selection. For example, asection criteria for a class can be a filter rule that determines whichobjects are included in the client view 5.

[0090] The filter rules are defined in the classes of the client view 5.They are expressed, for example, in a syntax similar to the SQLlanguage.

[0091] Attributes required for processing filter rules are referred toas Filter Attributes.

[0092] Consistency in the ZDS 1 is governed by the followingdefinitions:

[0093] The ZDS 1 assumes that the data within the master system 3 areconsistent at each point in time,

[0094] Consistency conditions exceeding the boundaries of the mastersystem have to be specified,

[0095] Attributes required for evaluating the consistency conditionsmust be included in KOM 4,

[0096] Consistency conditions can be defined in client views 5,

[0097] The consistency of the data must not be diminished by forwardingdata by the ZDS 1.

[0098] Consistency rules (as opposed to filter rules) are defined basedon a client view 5, i.e., this corresponds to the logical definitionthat a client view 5 has to be internally consistent.

[0099] If no consistency rules are defined on the client views 5, thenit is assumed that the corresponding data always mutually consistent.

[0100] Attributes required for evaluating consistency rules are referredto as Consistency Attributes.

[0101] The syntax of the consistency rules corresponds to the syntax ofthe filter rules.

[0102] As described above, a separate class category is modeled for eachsystem connected to the ZDS 1, which itself can contain two classcategories for the master view 6 and client view 5.

[0103] These categories include:

[0104] exactly those classes (with attributes and methods) and theirrelationships that are visible in the corresponding view, whereby theclass names of formed according to the aforementioned namingconventions,

[0105] at least one class diagram depicting the classes that areincluded in the view,

[0106] for each operation, the specification of the signature of thismethod by specifying object structures.

[0107] Mapping this information on the ZDS object model 10 makes itpossible to form a complete documentation of the object model whichrepresents the functional part of the technical concept. It is alsopossible to establish with this information configuration files whichcan be used in the ZDS application for mapping KOM 4 on the differentviews 5, 6.

[0108] The following sections describe how the two rules for forming theviews 5, 6 (Projection and Selection) and the specification of theinterface are mapped by operations in the ZDS object model 10.

[0109] Classes and relationships are projected in that only the classesand relationships that belong to the view are included in the classcategories of the views 5, 6.

[0110] These classes include only the attributes and operations thatbelong to the view. Moreover, the attributes in the classes of the viewshave the same name and type as the attributes of the correspondingclasses of the KOM 4. The same applies to operations where the name andthe interface should be identical.

[0111] View-specific descriptions of the elements included in the viewcan be displayed in the field “Documentation” of the correspondingspecification dialog.

[0112] The selection, i.e., an additional filtering, cannot be expressedin the Booch notation. The section criteria with the property “SelectionCriteria” of the class belonging to the view are therefore indicated inthe Rose model

[0113] Consistency rules are defined based on a client view 5. Theconsistency rules in the Rose model are therefore indicated in theproperty “Consistency Rules” of the client view category.

[0114] The ZDS 1 provides different types of services:

[0115] Retrieve services for using the data access service

[0116] Message services for using the message service

[0117] All services are generally mapped as methods in the object model10. No Call Parameters are defined for these methods, because they aredefined by existing C-API functions.

[0118] Selection criteria can also be indicated for services. Theselimit further the criteria defined for the classes. They are defined inthe property “Selection Criteria” of the corresponding method. Tosatisfy the existing rules for forming client and master views 5, 6, themethods have to be modeled according to the classes also in the KOM 4.

[0119] Complex tree structures are transferred at the interface for bothtypes of services. The configuration of the tree structures has to bespecifically defined for each service for generating the technicalconcept.

[0120] These data structures must be mappable on the correspondingviews, i.e.

[0121] Only known classes, attributes and relationships can be used

[0122] References to sub-objects can be formed from associations,wherein the name of the reference corresponds to the role name of theassociation

[0123] The cardinality of a relationship determines if this is a singleobject (cardinality ←1) or a list of objects (cardinality >1).

[0124] An exception exists:

[0125] If it is certain that by evaluating selection criteria for arelationship with the cardinality >1 exactly one object is supplied,then this can be represented in the data structure by indicating asingle object.

[0126] Attributized associations existing in the view are resolved, asindicated in FIG. 3 by using the Booch notation.

[0127] The corresponding tree structure is shown in FIG. 4. It ispossible to navigate from class A 19 via the class name of the linkclass 21 to the link class, wherein the cardinality of the relationshipon the side of the class B determines if one of several objects exist ofthe link class. It is then possible to navigate to the class B 20 fromthe link class via the role name (identifying attribute B) (FIG. 3).

[0128] Data access services (retrieve services) are defined for theclient systems 2 and master systems 3. Client systems 2 define thenecessary retrieve services that allows them access to the data definedin the client view 5.

[0129] Retrieve services for the master systems 3 are defined based onthe requirements of the client retrieve services. These use the dataaccess service for identifying the data that are requested by the clientsystems 2. Retrieve services are modeled in the object model as classmethods of the corresponding class.

[0130] Message services are defined within the ZDS object model 10 bothin the master views 6 and in the client views 5. Messages that themaster system 3 transmits to the ZDS 1 are defined in a master view 6.Messages that the ZDS 1 transmits to the client system 2 are defined ina client view 5.

[0131] A message is defined as a method of the respective class.

[0132] Client systems receive only messages that are of interest tothem, i.e. messages that affect the data set of the correspondingclient. The selection criteria has to be taken into account duringprocessing.

[0133] A message includes the following information:

[0134] a unique message ID,

[0135] information of the client view 5 for which the message isintended (argument “userview”),

[0136] a message type (argument “message”),

[0137] the time when the data included in the message are valid,

[0138] an indication from which master system 3 the message wastransmitted, and

[0139] the message data (in the form of a ZDS_OEDATA data structure)

[0140] message types.

[0141] The following types of messages exists:

[0142] New: similar to a constructor method of the class

[0143] Update: similar to a “normal” method of a class

[0144] Delete: similar to a destructor method of a class

[0145]FIG. 5 illustrates the basic structure of the message data. When amessage is processed in the CM component, the message data have to beread therein. A maximum of two entries exists in the data structure(function parameter “message_data”):

[0146] a Boolean value “filter” and

[0147] a ZDS_OEDATA structure “data”

[0148] The value “filter” exists in each update message transmitted to aclient system 2 and contains the value determined during evaluation ofthe filter rule. If no filter rule is defined for the client 2, then thevalue TRUE is entered. The result of the filter rule is required fordealing with update messages on the client side.

[0149] The substructure “data” is contained in each message, i.e., bothin the messages for the client systems 2 and also in the messages sentby the master systems 3 to the ZDS 1. The configuration of thesubstructure depends on the respective specification of the message.

[0150] The configuration of “data” in the client system 2 correspondsexactly to those elements that the client system 2 wishes to receive.The configuration of the corresponding message in the master system 3depends on the requirements of the different client systems 2 for acertain message type of a class: it's “data” structure has to be definedso that it includes all information of this master that are associatedwith this message.

[0151] The contents of the substructure “data” depends on the messagetype:

[0152] message type New: “data” contains the data of the new object.

[0153] message type Update: “data” contains the new data of the object.

[0154] message type Delete: “data” contains the data of the object to bedeleted.

[0155] When specifying an update message in a master view 6, it can beadditionally indicated if the old values also to be supplied. Thisinformation is displayed in the master view 6 in the ZDS property“Message Data Master” of the corresponding method.

[0156] When specifying an update message in a client view 5, it can alsobe indicated

[0157] if the client system 2 wishes to receive also the old values, and

[0158] if the client system 2 is interested in all values or only in thechanged values.

[0159] This information is displayed in the client view 5 in the ZDSproperty “Message Data Client” of the corresponding method.

[0160] As illustrated in FIG. 6, old values are displayed in updatemessages, if present, as follows: the data structure includes instead ofthe actual attribute value an object of the class “changed”. This objecthas the attributes “new” and “old” representing the new and oldattribute values, respectively.

[0161] The class “changed” is defined particularly for this purpose.Although this class is not used in the definition of the message datastructure, it exists in the data structure if the old values are to besupplied.

[0162] The example of FIG. 6 shows the data structure for the situationwhere the attribute A of the class C has been changed.

List of Reference Numerals

[0163]1 central data server ( ZDS)

[0164]2 client system

[0165]3 master system

[0166]4 conceptional object model (KOM)

[0167]5 client view

[0168]6 master view

[0169]7 data access

[0170]8 message service

[0171]10 ZDS object model

[0172]11 category (ZDS.-KOM)

[0173]12 subcategory

[0174]13 subcategory

[0175]14 category (view)

[0176]15 subcategory (master view)

[0177]16 subcategory (client view)

[0178]17 category (view)

[0179]18 subcategory (master view)

[0180]19 class

[0181]20 class

[0182]21 link class

1. Information processing system comprising a central communication unitZDS (1) for administration and forwarding of information from a dataset, at least one master information processing system (3), whichcommunicates with the ZDS (1) via an interface and provides the ZDS (1)with information upon request, at least one client informationprocessing system (2), which communicates with the ZDS (1) via aninterface and receives information from the ZDS (1) upon request,wherein the information administered by the ZDS (1) is described by anobject model (10) that includes a conceptual object model KOM (4)describing the entire data set made available by the master and clientsystems (2; 3), as well as views (5; 6) associated with the connectedsystems and describing the corresponding specific services related tothe KOM (4), with the views determining the elements of the data setadministered by the ZDS (1) that are recognized by the correspondingsystems (2; 3).
 2. Information processing system according to claim 1,characterized in that each master system (3) provides to the ZDS (1) theelements of its data set that are defined in a corresponding master view(6).
 3. Information processing system according to one of the claims 1or 2, characterized in that the elements of the data set for which thesystem has the data rights, are included in the master view (6) of aconnected master system (3).
 4. Information processing system accordingto one or more of the preceding claims, characterized in that eachclient system (2) has access via a data access service to the datadefined in a corresponding client view (5).
 5. Information processingsystem according to one or more of the preceding claims, characterizedin that the elements of the data set, for which the system can recallinformation from the ZDS (1), are included in the client view (5) of aconnected system (2).
 6. Information processing system according to oneor more of the preceding claims, characterized in that the views (5; 6)for the connected systems are formed from the KOM (4) by the operationsProjection and Selection.
 7. Information processing system according toone or more of the preceding claims, characterized in that a selectionis made through the operation Projection, which elements are to beincluded in a view (5; 6) in the form of classes, attributes, methods,relationships of the KOM (4).
 8. Information processing system accordingto one or more of the preceding claims, characterized in that individualobjects of the classes are selected by a Selection.
 9. Informationprocessing system according to one or more of the preceding claims,characterized in that a Selection is only possible in a client view (5).10. Information processing system according to one or more of thepreceding claims, characterized in that a filter rule is defined as aselection criteria for a class, with the filter rule determining whichobjects are included in the client view (5).
 11. Information processingsystem according to one or more of the preceding claims, characterizedin that the corresponding view (5; 6) of the ZDS (1) determines theelements of the KOM (4) recognized by the connected system (2; 3),wherein a view (5; 6) is described by: classes with their attributes andmethods (including interface) selection criteria relationshipsconsistency rules.
 12. Information processing system according to one ormore of the preceding claims, characterized in that at least twocommunication mechanisms in the form of a data access service and amessage service are provided to the connected master and client systems(2; 3) by the ZDS (1).
 13. Information processing system according toone or more of the preceding claims, characterized in that all servicesprovided by the ZDS (1) are defined as Methods in the object model. 14.Information processing system according to one or more of the precedingclaims, characterized in that selection criteria are applied to theservices which impose additional limitations to the criteria defined forthe classes.
 15. Information processing system according to one or moreof the preceding claims, characterized in that data access services aredefined for client and master systems (2; 3).
 16. Information processingsystem according to one or more of the preceding claims, characterizedin that client systems (2) define the data access services that aretechnically required and to be used for accessing the data defined inthe client view (5).
 17. Information processing system according to oneor more of the preceding claims, characterized in that data accessservices for the master systems (3) are defined from the requirements ofthe client data access services.
 18. Information processing systemaccording to one or more of the preceding claims, characterized in thatchanges in the data set of a master system (3) are transmitted to theZDS (1) via the message service and that the ZDS (1) provides thesechanges to the affected client systems (2).
 19. Information processingsystem according to one or more of the preceding claims, characterizedin that the message services are defined within the ZDS object model(10) both in master and client views (5; 6).
 20. Information processingsystem according to one or more of the preceding claims, characterizedin that a separate class category is generated for each system (2; 3)connected to the ZDS (1).
 21. Information processing system according toone or more of the preceding claims, characterized in that each classcategory can itself contain two class categories for master and clientviews (5; 6).
 22. Information processing system according to one or moreof the preceding claims, characterized in that the class category KOM(11) is subdivided into several subcategories (12; 13) formed accordingto certain criteria.
 23. Information processing system according to oneor more of the preceding claims, characterized in that the classcategories include: exactly those classes (with attributes and methods)and their relationships that are visible in the corresponding view (5;6), at least one class diagram illustrating the classes included in theview (5; 6), for each operation, the specification of the signature ofthis method by identifying object structures.
 24. Method for operatingan information processing system, characterized by: providing a centralcommunication unit ZDS (1) for administrating and forwarding informationof a data set, providing at least one master information processingsystem (3), which communicates with the ZDS (1) via an interface andprovides to the ZDS (1) information upon request, providing at least oneclient information processing system (2), which communicates with theZDS (1) via an interface and receives from the ZDS (1) information uponrequest, wherein the information administered by the ZDS (1) isstructured as an object model (10) that includes a conceptual objectmodel KOM (4) describing the entire data set made available by themaster and client systems (2; 3), as well as views (5; 6) associatedwith the connected systems and describing the corresponding specificservices related to the KOM (4), with the views determining the elementsof the data set administered by the ZDS (1) that are recognized by thecorresponding systems (2; 3).